(12) NACH DEM VERTRAG UBER DIE INTERNATIONALE ZUSAMMENARBEIT AUF DEM GEBBET DES 
PATENTWESENS (PCT) VEROFFENTLICHTE INTERNATIONALE ANMELDUNG 



(19) Weltorganisation fur geistiges Eigentum 
Internationales Btiro 

(43) Internationales VeroffenUichungsdatum 
3. Juni 2004 (03.06.2004) 




PCT 



(10) Internationale Veroffentlichungsnummer 

WO 2004/047385 A2 



(51) Internationale Patentklassifikation 7 : H04L 12/66 

(21) Internationales Aktenzeichen: PCT/DE2003/003848 

(22) Internationales Amneldedatum: 

20. November 2003 (20.1 1.2003) 



(25) Einreichungssprache: 

(26) Veroffentlichungssprache: 



Deutsch 
Deutsch 



(30) Angaben zur Prioritat: 

102 54 285.6 20. November 2002 (20.1 1.2002) DE 

(71) Anmelder (fur alle Bestimmungsstaaten mit Ausnahme von 
US): ROBERT BOSCH GMBH [DE/DE] ; Postfach 30 02 
20, 70442 Stuttgart (DE). 

(72) Erfinder; und 

(75) Erfinder/Anmelder (nur fur US): EIMERS-KLOSE, 



Doerte [DE/DE]; Pestalozzistrasse 68, 72762 Reutlingen 
(DE). HEINISCH, Cornelia [DE/DE]; Achalmstrasse 
34, 73734 Esslingen (DE). FISCHER, Joerg [DE/DE]; 
Konrad-Adenauer-Strasse 16a, 31139 Hildesheim (DE). 
GRAMANN, Timo [DE/DE]; Klettgaustrasse 14b, 79787 
Lauchringen (DE). 

(74) Gemeinsamer Vertreter: ROBERT BOSCH GMBH; 

Postfach 30 02 20, 70442 Stuttgart (DE). 

(81) Bestimmungsstaaten (national): JP, US. 

(84) Bestimmungsstaaten ( regional): europaisches Patent (AT, 
BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, 
HU, IE, IT, LU, MC, NL, PT, RO, SE, SI, SK, TR). 

VerofTentlicht: 

— ohm intemationalen Recherchenbericht und erneut zu ver- 
offentlichen nach Erhalt des Berichts 

[Fortsetzung auf der nachsten Seite] 



(54) Title: GATEWAY UNIT FOR CONNECTING SUB-NETWORKS, IN PARTICULAR IN VEHICLES 

(54) Bezeichnung: GATEWAY-EINHEIT ZUR VERBINDUNG VON SUBNETZEN, INSBESONDERE IN FAHRZEUGEN 



LS-CAN 



< 

ID 



Most 



:Rx- 
Most 



:CAN- 
Most 



:Rx- 
CAN 



:Tx- 
CAN 



:CAN- 
SP1- 



:Tx- 
Most 



:CAN- 
Most 



:CAN- 
CAN 



:SPI- 
Most 



:Rx- 
SPI 



SPI 



;CAN- 
SPI- 



,4Q 



:Rx- 
CAN 



:Tx- 
CAN 



HS-CAN 



(57) Abstract: The invention relates to a gateway unit for connecting sub-networks, in particular in vehicles. The inventive unit ac- 

Otuates at least one modular software logical gateway which transmits messages between exactly two sub-networks, thereby providing 
K with only one individual data channel. 
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(57) Zusammenfassung: Es wird eine Gateway-Einheit zur Verbindung von Subsystemen, insbesondere in Fahrzeugen vorgeschla- 
gen, bei welchem wenigstens ein modulares logisches Software-Gateway eingesetzt wird, welches Nachrichten zwischen genau zwei 
Subnetzen routet und auf diese Weise nur einen individuellen Kopplungspfad bereitstellt. 
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10 Gateway-Einheit zur Verbindung von Subnetzen. insbesondere in Fahrzeugen 

Stand der Technik 

Die Erfmdung betrifft eine Gateway-Einheit zur Verbindung von Subnetzen, 
1 5 insbesondere in Fahrzeugen. 

Urn neue Dienste im Fahrzeug zu ermoglichen ist eine Kommunikation der 
Steuereinheiten, die sich in unterschiedlichen Bussegmenten befinden, zwingend 
erforderlich. Eine solche Kommunikation kann nur stattfinden, wenn die 

2 0 unterschiedlichen Bussegmente iiber eine Gateway-Einheit bzw. Gateway-Einheiten 

miteinander verbunden sind. Eine Gateway-Einheit, die zwei Bussegmente miteinander 
verbindet, hat dabei die Aufgabe, Nachrichten, die auf einem Bussegment empfangen 
werden, auf ein anderes Bussegment weiterzuleiten (Routing). Die Komplexitat einer 
solchen Gateway-Einheit steigt mit der Anzahl der zu koppelnden Bussegmente. Bei der 

2 5 Auslegung der Netzkoppelarchitektur eines Fahrzeugs wird versucht, ein Optimum fur 

die Eigenschaften der tolerierbaren Verzogerung fur das Nachrichten-Routing, der 
Fehlertoleranz, der Flexibility der Erweiterbarkeit und der Kosten zu finden. Je nach 
Anwendurig werden zentrale Gateway-Einheiten mit einer Sternarchitektur oder mehrere 
Gateway-Einheiten, die z.B. mit einem Backbone-Bus verbunden sein konnen, eingesetzt. 

30 Die Gateway-Einheiten, uber die unterschiedliche Busse gekoppelt sind, sind konfiguriert 

(z.B. iiber Tabellen). Das heilJt fUr das reine Nachrichten-Routing auf ein anderes 
Segment ist somit keine Abanderung der Software erforderlich. Sobald sich aber die Art 
und die Anzahl der gekoppelten Bussegmente andern, ist ein erheblicher 
Anderungsaufwand erforderlich, bei dem nicht nur die bestehenden 

55 Konfigurationstabellen angepasst werden mussen, sondern die komplette Software 
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umgeschrieben werden muss, urn den neuen Anforderungen gerecht zu werden. Die 
Komplexitat der zentralen Konfiguration und der Routing-Software steigt also mit der 
Anzahl der gekoppelten Bussegmente enorm an. 

Vorteile der Erfindung 

Durch den modularen Aufbau einer Gateway-Einheit, bei welcher ein in Software 
ausgebildetes Gateway (Iogisches Software-Gateway) fiir das Routing von Nachrichten 
zwischen genau zwei Subnetzen zustandig ist, wird es ermoglicht, Gateways zu 
erweitern, ohne dass eine Anderung in der vorhandenen Software des Gateways und/oder 
in den vorhandenen Konfiguratioristabellen erforderlich ist. Durch das Hinzufugen oder 
Weglassen eines solchen modularen Gateways bei Anderung der Netztopologie werden 
solche AnderungsmaBnahmen vermieden. Entsprechend ist es mSglich, bei einer 
zentralen Gateway-Einheit ein Bussegment zu entfernen ohne bestehende 
Kopplungspfade zu beeinflussen. 

Ferner wird durch die oben genannten modularen Gateways eine Fehlerbegrenzung 
erreicht, da bei nicht funktionsfahigem Gateway die anderen Gateways unabhangig davon 
weiterhin ihre Aufgabe erfullen. Ein Fehler wird also auf das unmittelbar betroffene 
Gateway begrenzt, die Kopplung zu anderen Bussegmenten ist nicht beriihrt. 
Kommt es auf einem Bussegment zu einem Fehler, so werden die Nachrichten uber die 
anderen Bussegmente ohne Einschrankung weiter geroutet 

Ferner ist das oben skizzierte Konzept flexibel erweiterbar und passt sich der 
Netzkoppelarchitektur an. Wird ein zusatzliches Subnetz einem zentralen Gateway 
hinzugefugt, so miissen lediglich die zusatzlichen modularen Gateways hinzugefugt 
werden. Die bestehenden modularen Gateways sind davon nicht betroffen. Wird ein 
Subnetz entfernt, werden die Gateways, die auf dieses Subnetz koppeln, entfernt, die 
restlichen bleiben unverandert bestehen. 

Da ferner in einem logischen Gateway immer nur die Funktion enthalten ist, die fur das 
Koppeln der zwei unterschiedlichen Subnetze erforderlich ist, wird eineNachricht 
schnellst mdglich geroutet. Unnotiger Overhead fur das Routing einer Nachricht wird so 
vermieden. Da ein Iogisches Gateway genau fur die Kopplung von zwei Subnetzen 
zustandig ist, kann ferner der Informationsfluss gesondert kontrolliert werden, wenn der 
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Datentransfer zwischen einem Subnetz mit sicherheitskritischen Funktionen und einem 
Subnetz mit nicht sicherheitskritischen Funktionen stattfindet. Es wird somit also eine 
optimale Kontrollmoglichkeit fur eine Firewall-Funktionalitat bereitgestellt. Diese kann 
jeden Kopplungspfad individuell kontroliieren. So kann ein logisches Gateway, das 
Nachrichten uber eine Luftschnittstelle routet, zur Abwehr von externen Bedrohungen 
striktere Sicherheitsmechanismen implementieren als ein logisches Software-Gateway, 
das Nachrichten zwischen zwei CAN-Subnetzen im Fahrzeug routet und direkt keiner 
externen Bedrohung ausgesetzt ist. 

Ferner ermoglicht die dargestellte Architektur ein individuelles Aktiv- und/oder 
hiaktivschalten eines einzelnen oder mehrerer Gateways, so dass auf dies Weise abhangig 
von Systemzustanden ein oder mehrere Gateways ein- bzw. ausgeschaltet werden 
konnen. 

Ferner erfolgt eine Reduzierung der Komplexitat der gesamten Gateway-Einheit, da die 
einzelnen logischen Gateways untereinander uberhaupt nicht miteinander verknupft sind. 
Es spielt keine Rolle, ob z.B. drei logische Gateways auf einem zentralen Gateway oder 
auf drei getrennten Punkt-zu-Punkt-Gateways ablaufen. 

Weitere Vorteile ergeben sich aus einer konkreten Ausgestaltung der logischen 
Gateways, nach der in jedem Gateway Routingtabellen vorgesehen sind, uber die das 
Routing der Nachrichten abgewickelt wird und die unabhangig von der Software des 
Gateways sind. Durch diesen tabellenbasierten Ansatz wird es ermoglicht, ein Tool zur 
Konfiguration der Gateway-Software einzusetzen. Dieser Ansatz fiihrt auch in 
vorteilhafter Weise zu einer Priorisierungsmoglichkeit der Nachrichten, so dass 
bestimmte Nachrichten, die bevorzugt geroutet werden sollen, eine hohere Prioritat 
zugeordnet werden kann als anderen Nachrichten. 

Ferner ist in vorteilhafter Weise ein Scheduler vorgesehen, der trotz der Aufteilung in 
mehrere modulare Software-Gateways gewahrleistet, dass die Reihenfolge des 
Nachrichten-Routings eingehalten wird. Auf diese Weise kann eine Nachricht, die zuerst 
im Gateway angekommen ist, das Gateway auch zuerst wieder verlassen. 

Weitere Vorteile ergeben sich aus der nachfolgenden Beschreibung von 
Ausfuhrungsbeispielen bzw. aus den abh&ngigen Patentanspriichen. 
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Zeichnung 

Die Erfindung wird nachstehend anhand der in der Zeichnung dargestellten 
Ausflihrungsbeispielen naher erlautert. 

Figur 1 zeigt das Grundprinzip der beschriebenen Architektur einer Gateway-Einheit, 
welche drei Bussegmente miteinander verbindet. 

Figur 2 zeigt ein bevorzugtes Ausfiihrungsbeispiel eines solchen Gateways, welches 
Nachrichten zwischen einem Lowspeed-CAN, einem Highspeed-CAN und einem SPI- 
Bus vermittelt. 

Figur 3 zeigt eine zentrale Gateway-Einheit zur Kopplung zwischen vier Subnetzen, 
wahrend in 

Figur 4 Punkt-zu-Punkt-Gateway-Einheiten zur Kopplung der vier Subnetze mit Hilfe der 
beschriebenen Gateway-Architektur dargesteilt sind. 

Figur 5 schlieftlich zeigt ein in eine Steuereinheit integriertes Gateway anhand eines 
Schichtenmodelis. 

Beschreibung von Ausflihrungsbeispielen 

In Figur 1 ist eine Gateway-Einheit 10 dargesteilt, an die drei Bussegmente 1, 2, 3 
angekoppelt sind und die die Aufgabe hat, Nachrichten von einem Bussegment auf eines 
der anderen oder beide andere Bussegmente zu verbinden (routen). Grundprinzip der 
dargestellten Architektur sind die modularenb Gateways (logischen Software-Gateways) 
12, 13, 23, wobei ein solches Gateway fiir das Routing von Nachrichten zwischen genau 
zwei Subnetzen zustandig ist. Somit routet das Gateway 12 Nachrichten von 1 nach 2 und 
umgekehrt, das Gateway 13 Nachrichten von 1 nach 3 und umgekehrt, das Gateway 23 
Nachrichten von 2 nach 3 und umgekehrt. Jedes logische Software-Gateway beschreibt 
daher einen individuellen Koppelpfad zwischen zwei Subnetzen. bzw. Bussegmenten. Die 
Gateways 12, 13, 23 sind dabei als Software-Programme ausgestaltet, mit deren Hilfe die 
protokollspezifischen Anpassungen vorgenommen werden, die fiir ein Nachrichten- 
Routing zwischen den beiden Subnetzen erforderlich sind. Je nach Ausfiihrungsbeispiel 
handelt es sich bei jedem Subnetz um ein individuelles Ubertragungsmedium. Subnetz 1 
kann z.B. ein Lowspeed-CAN, Subnetz 2 ein Highspeed-CAN und Subnetz 3 ein SPI-Bus 
sein. Kommt ein neues Subnetz hinzu, beispielsweise ein MOST-Bus, so werden 
zusatzliche logische Software-Gateways integriert. Die Bestehenden miissen nicht 
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geandert werden. Wird ein Subnetz entfernt, beispielsvveise der SPI-Bus, so werden die 
logischen Software-Gateways 13 und 23 entfernt. Um eine universelle Gateway-Funktion 
zu haben, sind logische Software-Gateways fur alle Kopplungsrnoglichkeiten zu 
schreiben. Diese werden dann je nach Auslegung des zu realisierenden Gateways zum 
Gesamtsystem kombiniert. Im Regelfall wird es so sein, dass nicht alle Subnetze direkt 
miteinander gekoppelt sind, so dass nur ausgewahlte Kopplungspfade mit ausgewahlten 
logischen Software-Gateways zu versehen sind. Soil jedes Subnetz mit jedem anderen 
gekoppelt werden, so benotigt man N*(N-l)/2 logische Software-Gateways. Die Variable 
N entspricht dabei der Anzahl der im Gesamtsystem vorhandenen Subnetze. Fur drei 
Subnetze ergeben sich damit 3 logische Software-Gateways, fur vier Subnetze 6 und fiir 
fiinf Subnetze 10. Ob sich diese logischen Software-Gateways in einem zentralen 
Gateway befinden oder in mehreren verteilten Punkt-zu-Punkt-Gateways spielt eine 
untergeordnete Rolle. 

Figur 2 zeigt ein detaillierteres Ausfuhrungsbeispiel der Grundziige der modularen 
Gateway- Architektur gemaB Figur 1. Das Gateway 10, welches vorzugsweise als 
Programm in einem Mikrocontroller einer Steuereinheit realisiert ist, umfasst neben den 
dargestellten modularen Software-Gateways (iCANCAN, :CANSPI) busspezifische 
Sendeeinheiten, die den Zugriff auf das Busmedium kontrollieren. Jedem Bussegment 
sind Empfangsobjekte zugeordnet (:Rx-CAN, :Rx-SPI), welche die Entscheidung treffen, 
in welches logische Software-Gateway eine ankommende Nachricht geroutet wird. 
Entsprechend gibt es fiir den Sendevorgang busspezifische Sendeobjekte (:TxCAN 5 
:TxSPI) , die den Zugriff auf den jeweiligen Bus kontrollieren und verhindern, dass 
mehrere modulare Software-Gateways das Sendemedium gleichzeitig belegen. 

Die Software-Gateways (in Figur 2: CANCAN:CANSPI) setzen sich intern aus mehreren 
Software-Objekten zusammen, die ankommende Nachrichten zwischenpuffern und die 
protokollspezifischen Anpassungen vornehmen. Eine einfache Anpassung ist z.B., dass 
eine CAN-Nachricht vom Highspeed-CAN mit der ID 100 auf den Lowspeed-CAN mit 
der ID 200 gesendet werden muss. Diese protokollspezifischen Anpassungen werden 
dann durch entsprechende Programme (z.B. im einfachsten Fall durch eine Tabelle) 
vorgenommen. Fiir die protokollspezifischen Anpassungen, die innerhalb der logischen 
Software-Gateways durchgefuhrt werden, kommen Konfigurationstabellen zum Einsatz. 



WO 2004/047385 



- 6 - 



PCT/DE2003/003848 



In einer bevorzugten Ausfllhrung werden die busspezifischen Empfangsobjekte iiber 
sogenannte Routingtabellen konfiguriert, mit deren Hilfe entschieden wird, ob eine 
ankommende Nachricht an kein, an ein oder an beide logischen Software-Gateways 
weitergegeben wird. In der Routing-Tabelle werden somit fur jeden ankommenden 
Nachrichtentyp die Weiterbehandlung der Nachricht abgelegt. Ferner kann durch 
unterschiedliche Schnelligkeit der Busse es vorkommen, dass von einem zum anderen 
Bussegment nur jede 5. Nachricht eines bestimmten Typs (z.B. Motordrehzahl) 
weitergeleitet wird. Auch dies kann mittels der genannten Routingtabellen im 
Empfangsobjekt realisiert sein. Diese Routingtabellen sind dabei unabhangig vom 
Source-Code des eigentlichen Gateways, so dass eine Veranderung der Routingtabellen 
nicht oder nur unwesentliche Andemngen der Software des betrofffenen modularen 
Gateways nach sich zieht. Die busspezifische Empfangseinheit sucht die gefundene 
Nachricht in der Routing-Tabelle auf und entscheidet aufgrund der darin enthaltenen 
Informationen, welches logische Software-Gateway die Nachricht zur Weiterverarbeitung 
erhalt. 

Die busspezifischen Sendeeinheiten, bzw. die dort vorgesehenen Programme, 
kontrollieren den Zugriff auf den Bus. 1st der Bus gerade belegt, so stellen sie sicher, dass 
von keinem logischen Software-Gateway gesendet wird. 

Zusatzlich puffern wie oben erwahnt die logischen Software-Gateways die Nachrichten 
zwischen, um einen Nachrichtenverlust zu verhindern, z.B. dann, wenn das Bussegment 
auf dem gesendet werden soil, gerade belegt ist. Eine Nachricht wird also vor ihrer 
direkten Weiterleitung in einer Warteschleife abgelegt. Das Ablegen einer Nachricht in 
dieser Warteschleife wird beim internen Scheduler der Gateway-Einheit vermerkt. Dieser 
veranlasst dann das Senden der Nachricht, indem er eine Nachricht an das entsprechende 
modulare logische Software-Gateway sendet. Dieses veranlasst dann das Versenden der 
Nachricht. Will also ein logisches Software-Gateway eine Nachricht senden, so muss es 
diesen Sendewunsch beim Scheduler anmelden. Von der Reihenfolge der Anmeldung ist 
es abhangig, welches Software-Gateway zuerst die Berechtigung fur das Senden einer 
Nachricht erhalt. Dieses Konzept stellt die Einhaltung der Reihenfolge der Nachrichten 
sicher. Gibt es besondere hochpriorisierte Nachrichten im System, so stellt der Scheduler 
mehrere Methoden bereit, welche von den logischen Software-Gateways aufgerufen 
werden konnen, um einen Sendewunsch anzumelden. Der Scheduler arbeitet dann immer 
zuerst die hochpriorisierten Anforderungen ab und dann die normalen und erteilt 



WO 2004/047385 



- 7 - 



PCT/DE2003/003848 



prioritatenabhangig Sendeberechtungen an die logischen Software-Gateways. 
Beipsielsweise istjede Sendewunsch miteinem die Prioritat der Nachricht 
reprasentierenden Datum versehen oder der Scheduler umfasst eine Tabelle, in der die 
Prioritaten der Nachrichten vermerkt ist, aus der der Scheduler die Prioritat ausliest. 

Durch die oben dargestellte Architektur und Vorgehensweise ist man in der Lage, die 
Gateway-Einheit iiber Tabellen zu konfigurieren, ohne deren Software selbst abzuandern. 
Beispielsweise kann iiber eine Abanderung der Parametersatze im Speicher das Gateway 
fur ein anderes Nachrichten-Routing umprogrammiert werden. Werden die gleichen 
Schnittstellen verwendet, so lasst sich die Gateway-Software ausschlieBIich iiber 
Parametersatze konfigurieren. Bei dem Anschluss anderer Schnittstellen an das Gateway, 
ist ein modularer Software-Baustein in das Gateway zu integrieren. Somit werden 
unterschiedliche Gateway-Konfigurationen durch das Zusammenfiihren von Software- 
Modulen beispielsweise aus Bibliotheken und aus dem Bereitstellen der Routing- 
Information generiert. Die Neuintegration einer CAN-Schnittstelle mit neuer CAN- 
Matrix beschrankt sich im wesentlichen auf das Eingeben der neuen Routing-Information 
in die Routing-Tabelle. So konnen CAN-CAN-Gateways unterschiedlicher Baudraten in 
kurzester Zeit in ein System eingepasst werden. Die Testbarkeit und Verifizierung des 
entstehenden Codes werden dadurch vereinfacht, weil der konfigurationsunabhangige 
Code zentral getestet wird und neben dem Systemtest ausschliesslich ein Integrationstest 
fur das neue logische SW-Gateway bzw. die neue Konfiguration durchgefuhrt werden 
muB. 

Figur 3 zeigt ein Gateway 1 0 zur Kopplung 4 unterschiedlicher Bussegmente, einen 
Lowspeed-CAN, einen Highspeed-CAN, ein SPI-Bus und einen MOST-Bus. Die 
vorstehend beschriebene Architektur ist auch hier eingesetzt, wobei logische Software- 
Gateways (rCAN-MOST, :CAN-SPI, :CAN-CAN, :SPI-MOST) eingesetzt werden, die 
jeweils einen individuellen Kopplungspfad realisieren. Daneben sind busspezifisch 
Empfangermodule (:Rx-Most, :Rx-CAN, :Rx-SPI) und Sendemodule (:Tx-Most, :Tx- 
CAN, :Tx-SPI) wie vorstehend beschrieben darstellt. Die dargestellte Architektur zeigt 
eine zentrale Gateway-Einheit, welche die genannten vier Bussegmente miteinander 
verbindet. In Figur 4 ist eine andere Netzwerktopologie dargestellt, welche sechs Punkt- 
zu-Punkt-Gateway-Einheiten 10a, 10b, 10c, lOd, lOe und lOfaufweist. Jedesdieser 
Punkt-zu-Punkt-Gateways enthalt die oben dargestellte logische Software-Gateway- 
Struktur mit Sende- und Empfangerelementen zur busspezifischen Anbindung. Es zeigt 
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sich, dass durch die oben dargestellte Architektur die physikalische 
Netzkoppelarchitektur zwischen den beiden Extremen zentrales Gateway und Punkt-zu- 
Punkt-Gateway alle denkbaren Mischforrnen enthalten kann. Die Software- Architektur ist 
unabhangig von der physikalischen Netzkoppelarchitektur, so dass sie die Kopplung in 
alien denkbaren Architekturen erlaubt. Unter$chiedlich kann sein, dass bei der zentralen 
Gateway- Variante die Software auf einem Mikrocontroller, in der dezentralen Variante 
auf unterschiedlichen Controllern ablauft. 

Zur Konfiguration der Gateway-Einheit ergeben sich verschiedene Moglichkeiten. Die 
Konfiguration der Routing-Entscheidung erfolgt uber Routing-Tabellen. In diesem Fall 
entscheiden die busspezifischen Empfangsobjekte, in welche logischen Software- 
Gateways eine Nachricht weiterzuleiten ist. Diese Empfangsobjekte werden deshalb mit 
Routing-Tabellen konfiguriert, welche angeben, welche Nachrichten in welches Subnetz 
und ggf. unter welchen Randbedingungen (z.B. jede 5., etc.) weiterzuleiten sind. Die 
Software der Software-Gateways realisiert dann die busspezifischen Anpassungen und ist 
von dem eigentlichen Routing- Vorgang unabhangig. Die Konfiguration der Software- 
Gateways erfolgt dann durch Anpassung von Protokollparametern. In diesem Fall werden 
die logischen Gateways uber Tabellen konfiguriert, die angeben, wie die Protokoll- 
Parameter umzusetzen sind. Hier kann konfiguriert werden, dass eine Nachricht mit dem 
Identifikationscode 1 00 bei dem Versenden auf dem anderen Netzsegment die 
Identifikationsnummer 200 tragen muss. Ferner sind, um die Gateway-Software an die 
unterschiedlichen Netzkoppelarchitekturen anzupassen, die Routing-Tabellen, mit denen 
die busspezifischen Empfangsobjekte konfiguriert werden, aufzuteilen bzw. 
zusammenzufuhren. Diese Aufgabe wird durch einen internen Scheduler erledigt, 
welcher die logischen Software-Gateways in einer zentralen Gateway-Einheit 
untereinander koordiniert. Der Scheduler muss fur die verschiedenen Gateway-Varianten 
individuell generiert werden. 

In einer anderen AusfUhrungsform, die in Figur 5 dargestellt ist, handelt es sich bei dem 
Gateway um kein Standalone-Gateway, sondern um ein Gateway, das in ein Steuergerat 
mit zusatzlichen Anwendungsfunktionen integriert wird. Dort kann die Gateway- 
Software auch die Funktionalitat eines normalen Kommunikationsdecks tibernehmen. 
Das heiBt, es muss hier auch moglich sein, Nachrichten zu den eigentlichen 
Anwendungen weiterzuleiten und Nachrichten zum Versenden von diesen 
entgegenzunehmen. Hierzu werden weitere Objekte benotigt, welche die Fahigkeit 
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besitzen, die schichtspeziflschen Protokollparameter zu entfernen bzw. hinzuzuftigen, urn 
dieNachricht in die nachsthohere bzw. nachstniedrigere Schicht weiterzureichen. Diese 
zusatzlichen Objekte sind in der Regel Bestandteil der Software des normalen 
Kommunikationsnetz. Figur 5 zeigt das Schichtenmodell eines Steuergerats 100, in 
welchem ein CAN-CAN-Gateway integriert ist Dabei wird das Anwendungssystem I 
und das Kommunikationssystera II unterschieden. Es sind drei Schichten 1, 2, 3 
abgebildet, wobei in einer ersten Schicht ein Treiber 102 fur den Lowspeed-CAN und ein 
Treiber 104 fur den Highspeed-CAN vorgesehen sind. Ferner wurden in der 
Vermittlungsschicht 3 zusatzliche Objekte eingefugt (CAN-Schicht 3), die Ober die 
Empfangs- und Sendeobjekte Rx3 und Tx3 mit den Anwendungen A, B und C 
kommunizieren. Diese zusatzlichen Objekte fuhren, falls erforderlich, eine 
Zwischenpufferung der Nachrichten durch und fugen protokollspezifische Parameter 
hinzu oder entfernen diese. Das logische Software-Gateway, das in diese Schicht 
integriert ist (CAN-CAN) routet Nachrichten vom einen Bus zum anderen. Die 
Empfangs- und Sendeobjekte Rx2 und Tx2 werden entsprechend dem vorstehend 
Beschriebenen fur das Routing von Nachrichten zwischen den beiden CAN-Bussen 
verwendet Sie stellen die Schnittstellen zwischen den Schichten dar. In einer weiteren 
Ausfuhrung ist durch entsprechende Erweiterung es moglich, zwei Subnetze auf 
unterschiedlichen Schichten zu koppeln. Dies ist beispielsweise dann erforderlich, wenn 
ein Transport-Protokoll (z.B. ISO TP) zum Einsatz kommt. In diesem Fall existiert dann 
pro Schicht, in der eine Kopplung stattfindet, ein logisches Software-Gateway. So kann 
beispielsweise ein CAN-CAN-Gateway in der Schicht 3 vorgesehen sein, welches CAN- 
Nachrichten (z.B. Geschwindigkeitsinforrnation oder Tankfiillstand) in der Schicht 3 
transportieren wahrend ein weitere CAN-CAN-Gateway in einer Schicht 4 
Transportinformationen koppelt, welche beispielsweise einen Text fur die Anzeige im 
Fahrzeugcomputer enthalt. Eine Kopplung in hoheren Schichten kann auch erforderlich 
sein, um den Inhalt einer Nachricht die weitergeleitet werden soli uberpriifen zu konnen. 
Der Inhalt kann nur dann analysiert werden, wenn die komplette Nachricht ernpfangen 
ist. 
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Patentanspruche 

1. Gateway-Einheit zur Verbindung von Subnetzen, insbesondere in Fahrzeugen, wobei 
die Gateway-Einheit wenigstens zwei Subsysteme miteinander verbindet, dadurch 
gekennzeichnet, dass die Gateway-Einheit aus wenigstens einem modularen 
Software-Gateway besteht, welches Nachrichten zwischen genau zwei Subnetzen 
routet. 

2. Gateway-Einheit nach Anspruch 1, dadurch gekennzeichnet, dass wenigstens drei 
Subnetze an die Gateway-Einheit angeschlossen sind, wobei modulare Software- 
Gateways eingesetzt werden, wobei jedes modulare Software-Gateway Nachrichten 
zwischen genau zwei Subsystemen routen. 

3. Gateway-Einheit nach einem der vorhergehenden Anspriiche, dadurch 
gekennzeichnet, dass ferner fur jedes Subnetz busspezifische Empfangsobjekte 
vorgesehen sind, welche die ankommenden Nachrichten an ausgewahlte Software- 
Gateways weitergeben. 

4. Gateway-Einheit nach Anspruch 3, dadurch gekennzeichnet, dass die 
Empfangsobjekte Routing-Tabellen umfassen, in denen die Behandlung 
ankommender Nachrichten konfiguriert sind. 

5. Gateway-Einheit nach einem der vorhergehenden Anspriiche, dadurch 
gekennzeichnet, dass ferner fur jedes Subnetz busspezifische Sendeobjekte 
vorgesehen sind, welche den Zugriff auf den jeweiligen Bus kontrollieren. 
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6. 



5 7. 



Gateway-Einheit nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, dass das modulare Software-Gateway ankommende Nachrichten 
zwischenpuffert und protokollspezifische Anpassungen vornimmt 

Gateway-Einheit nach einem der vorhergehenden Anspriiche, dadurch 
gekennzeichnet, dass bei Integration des Gateways in ein Steuergerat mit 
Anwendungssystem wenigstens ein modulares logisches Gateway in einer Schicht 
des Kommunikationssystems vorgesehen sein konnen, wobei das logische Gateway 
genau zwei Subsysteme verbindet 
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